1. Field of the Invention
The present invention relates to the testing of software functions and their error recovery routines, and more specifically, to controlling the timing of error injection into a function under test.
2. Description of the Related Art
Software testing, which documents that a piece of software is operating correctly, is an important component of software development, and is often the most costly part of the process. After the developer is satisfied that the finished software product will operate satisfactorily under normal operating conditions, the software is turned over to testers who will run a set of tests to examine the performance of the software when unforeseen errors (also referred to as “faults”) are intentionally injected into the operational system.
Software error injection is a method that may be used to test the resiliency of a system's software to a variety of errors. It is frequently used to identify a system's software error vulnerabilities, in order to improve the software to remove flaws prior to delivery to the customer. Alternately, the customer may use software error injection to test customer-defined applications for their own use or subsequent release to another customer.
The software to be tested may be a “function” that can be called by a customer at the application level. The “function” is a unit of processing (software or firmware) that includes a recovery routine to handle unforeseen errors. A “function” may be an elementary function such as Open, Close, Read, Write, allocate or deallocate a file, acquire or free storage, create or delete a subtask or display a screen image of an Operating System (OS). Alternately, a “function” may be a customer-defined application that runs on the OS.
One common error injection practice is to insert “hooks” at fixed locations of logic in the source code of a particular function under test. When enabled, the hooks inject an error at the fixed location into the running source code that invokes the function's error recover routine. This practice requires modification of the source code and provides no timing diversity to the invocation of the error recovery routine. The hooks are disabled prior to sending the source code to the customer.
Another common error injection practice is to externally inject the errors at totally random times into the running source code. This practice does not require modification of the source code but is inefficient. The particular function under test may occupy a relatively small time window of the entire process. Random error injection is quite likely to miss the function under test and invoke an error recovery process of no interest.